在繼續討論如何建造一個機器學習解決方案之前，我們要先來討論這個模型要放在什麼樣的系統之中，接下來三天的時間，將從上而下的了解一個 Fintech 系統會有哪些元件，並以 DS 的角度去思考如何在這樣的系統下提供 Solution

效能貧頸

如果你今天建造了一個網路銀行的系統，只有幾百幾千人用戶，不太會遇到效能上的瓶頸，但如果今天是個好幾十萬百萬人用的系統，大量的請求勢必會讓 API 執行速度變慢，而這樣的延遲可能會讓想要提款的用戶抓狂！

試想有一個資料科學家，為了要研究一個特徵是否顯著，寫了一個充滿 JOIN GROUP BY, Sub Query 和 RANKING 的 SQL Command，一次查詢的執行時間就需要耗費好幾十分鐘，而 Query 期間所有的表都會被 Lock，而這個 Lock 很有可能就會導致 API 響應時間變長，最終導致用戶抓狂，所以第一個"我們將資料存儲分成 OLAP 和 OLTP 兩個類別，T 表示 Transaction，A 表示 Analytics"，來區分不同起用用圖，我們用以下的圖來解釋：

當有一個從 APP 端發出提款的請求時，APP 端就會對資料庫中的兩個資料表進行讀好的操做

1. 用戶資產表：將用戶的餘額減去他提取的金額
2. 資金流動表：紀錄用戶提領的資訊，包含時間和金額等，當然也可以進一步紀錄用戶提領時的設備資訊、IP 位置等額外資訊

到目前為止，就是一個常見的 Web Application 設計，這個資料庫可以是任何雲服務資料庫如 AWS RDs 或自己架的 SQL等等，這些 DB 通常都會有一定程度的 Read/ Write Lock，目的是為了預防 Data Race 等現象發生，舉例來說，有個充滿 QA 性格的用戶，可能會嘗試在短時間內狂提款，如果其中一筆提款發生的當下，因為資料庫還來不及扣掉上一筆提款，導致用戶超額提款，就會造成一定損失，有了這些 Lock 就可以確保上一筆的資料已經更新好了。

但這樣的 Lock 也會造成其他用戶的提款需求被耽誤，更不用說這時候要是還有一批資料科學家和分析師都在的取這資料庫的內容，常常會在這種大型系統設計架構中看到不同的 Paritioning 和 Sharding 來解決 API 請求延遲的問題，但這解決方法主要是解決用戶請求延遲的問題，對於解決資料團隊的問題，一種常見設計就是把資料應用場景拆分為 OLTP 以及 OLAP，其中 OLTP 可以想像成就是原本的資料庫跟 API 系統，而 OLAP 則是把 OLTP 的資料同步備份一份到另一個儲存空間來做使用

OLAP 可以是另外一個 MySQL Database 或是任何儲存空間，比較常見的是使用 Amazon S3 搭配 Hadoop/ Spark 生態系的運算系統, 通常這裡的需求有以下特性

1. 不需要即時的讀取
2. 會需要對於歷史資料做大量計算，由於處理計算

同步的方法常常會見到透過 Message Queue 在消息寫入 OLTP 時同步寫入 OLAP 之中，也有整批資料定時同步的方式，在同步的過程中，常常會加入一些 ETL Pipeline 來將同步的資料做分層，從上面的例子中，最原始的資料有用戶資產以及資金流動表，我們舉資金流動表為例，一個 ETL Pipeline 依照處理層級簡單到複雜 (或說從原始到抽象)，依序為：

• 原始資金流動表
• 每個用戶每天流入與流出總量 (依據用戶以及時間做 Group By)
• 每天公司內用戶的資金流動 (只依據時間做 Group By)
• 公司總資金流動，可以用來做資產負債的報表 (除了資金流動外，加入其他項目的資金流動)

可以看出上面像是一個 Funnel 依樣一層層的聚合下來，有時候會用 DatawareHouse 分層的概念來設計這個 Funnel 今天的最後我們來介紹今天提到的幾個系統架構元件：

• Message Queue 是一個允許應用程序通過消息進行通信的服務。在高QPS的環境下，它可以平衡負載並確保數據的一致性。例如，當用戶提款時，可以將提款事件放入消息隊列，然後由後端服務逐一處理
• API (應用程序編程接口) 提供了一個標準化的方式讓不同的系統元件進行交互。例如，APP 端可以通過 API 請求資料庫進行提款操作
• Pipeline 數據管道用於數據的轉移和處理。例如，可以定期將 OLTP 系統的數據複製到 OLAP 系統進行分析
• Storage 存儲在這裡有多個層次，從數據倉庫（DW）到不同的數據存取層（例如 DWD、DWS、DWA）。每個層次都有其特定的目的和優化方式。例如，DWD 可能是原始數據的詳細存儲，而 DWA 則可能是經過聚合和分析的數據

結論

構建一個大型系統以滿足高 QPS 和大量用戶的需求是一個複雜的過程。通過理解和合理分配 OLTP 和 OLAP 的任務，並且有效利用 Message Queue、API、Pipeline 和 Storage 等工具和概念，可以創建一個可靠、可擴展和高效的系統。這樣的設計不僅確保了業務的順利運作，還為數據分析和洞察提供了強大的支援

最後分享一個心得，在做這樣系統設計的時候，要把設計理念, 使用工具和程式碼分開，我覺得一個提供解決方案的好流程是先去了解各個工具他們背後有什麼樣的設計理念，然後再去思考你的設計理念是什麼，每個理念背後都有一個或多個想要解決的問題，最後才去選你的工具，如果一開始就綁定一個工具，在不知道某項功能背後目的情況下直接使用一個工具常常會錯誤的使用而堆疊技術債，屆時還需要花不少時間去設計 Anti-Pattern 來彌補